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[57] ABSTRACT 


Establishing a language specific linkage between high- 
level graphics application programs written in a specific 
programming language and different intermediate-level 
graphics processors permit a graphics application pro- 
gram to be transported between and used in different 
graphics processing systems. A single, portable graph- 
ics application program can be used with any of the 
graphics processors with which an application language 
linkage has been established to produce graphs on an 
output device. 
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LANGUAGE BINDINGS FOR GRAPHICS 
FUNCTIONS TO ENABLE ONE APPLICATION 
PROGRAM TO BE USED IN DIFFERENT 
PROCESSING ENVIRONMENTS 


This is a continuation of application Ser. No. 
06/856,710 filed Apr. 28, 1986, now abandoned. 


BACKGROUND OF THE INVENTION 


The invention is in the field of computer graphics, 
and more particularly concerns the operation of diverse 
graphics processors in response to a single graphics 
application program written in a certain programming 
language, the response of any graphics processor af- 
forded by means of a set of common language linkages 
that translate the application program functions into 
sets of commands and data for the processor. 

As is known in the art, a graphics processor is a soft- 
ware construct embracing a set of callable subroutines, 
functions, or commands that provides an interface be- 
tween graphics application programs written in device- 
independent languages and a graphics output device 
that produces graphs defined by the application pro- 
grams. The graphics processor constitutes an intermedi- 
ary between an application program written in a high- 
Jevel, user-comprehendible programming language and 
device-dependent graphics device processors, which 
respond to sets of low-level instructions. The volume by 
J. Foley and A. Van Dam, entitled ‘Fundamentals Of 
Interactive Computer Graphics,” Addison-Wesley, 
1982, 1984 is instructive in the characteristics and opera- 
tions of graphics processors. 

In the past, the structure and operation of a graphics 
processor have had to take into account the characteris- 
tics of the software and hardware context within which 
the processor operates. Thus, a representative graphics 
processor is the graphics data display manager 
(GDDM) processing subsystem designed for operation 
in the main frame computer environment exemplified 
by the System 370 computing system available from 
IBM. The GDDM provides a graphics-output-device- 
independent interface to an application programmer, 
receives application language function or subroutine 
calls which set processor operational conditions and 
activate processor graphical primitive commands, and 
operates an output device driver, which produces graph 
representations corresponding to the called commands 
and having attributes determined by the set conditions. 

Another graphics processor is represented by the 
proposed Computer Graphics Interface (CGI) Standard 
X3.122 promulgated by ANSI. The Computer Graphics 
Interface defines the characteristics of a graphics pro- 
cessor which stands between output device-specific 
drivers and output device-independent application pro- 
cesses in a graphics environment. For application pro- 
grams, the CGI processor performs receiving and oper- 
ating functions that correspond to those of the GDDM. 
However, the CGI assumes a basic set of graphics prim- 
itives such as shapes, lines, and text characters, and 
associates with each set of primitives a respective set of 
primitive attributes such as color, line thickness, and 
character type. The CGI receives the application pro- 
gram graphics command and attribute information in 
the form of one or more standard data objects called 
“metafiles.” A metafile is a device-independent descrip- 
tion of a graph or graph portion in terms of graphical 
primitive elements such as lines or text and primitive 
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2 
attributes such as line color and text style. The metafiles 
received by the processor cause it to operate a specified 
output device driver. An IBM product, the personal 
computer AT/370, has available a graphics processor 
referred to as the Virtual Device Interface (VDD, 
which embodies the CGI Standard. 

It will be evident to those skilled in the art that the 
subroutines employed by a GDDM-type processor to 
transform application program statements to graphical 
primitive commands and attributes differ from those of 
a CGI processor. Other differences between the proces- 
sors can exist. For example, although both the GDDM 
and the VDI embodiments employ point coordinates in 
line drawing and object positioning, the processors use 
different structures to organize the data points: the 
GDDM point array is organized as (xi, X2, . . « »Xn); 
(Y1,Y2, ---:Yn), While the VDI structures its points in the 
form (x11), . - - (%nYn). Further distinctions include: 
different character codes; different color representation 
and indexing; and different forms of representation for 
graphical primitive attributes. 

From the standpoint of programmer efficiency, it 
would be desirable to enable different graphics proces- 
sors to respond uniformly to a single high-level graphics 
application language program. This would permit an 
application programmer to create a graphics program 
using a single set of statements, which would result in 
the creation of identical graphs using any one of a num- 
ber of different graphics processing facilities. This prop- 
erty is commonly called portability. However, to date, 
application programmers must construct graphics pro- 
grams that are tailored to the specific characteristics of 
the graphics processing service embodied in the com- 
puting facility available to the programmer. Thus, even 
when the programmer employs the same graphics appli- 
cation language to operate different graphic processing 
services, the programmer must construct an application 
program tailored to the specific graphics processor. In 
this regard, then, graphics application programs are not 
portable between different processing facilities, even if 
expressed in the same language. 

Therefore, there is an evident need for a construct 
that will provide a mode of establishing linkages to any 
of a variety of different graphics processors from a 
single graphics application program rendered in a par- 
ticular programming language. 


SUMMARY OF THE INVENTION 


The primary objective of this invention is, then, to 
provide such linkages in the form of common language 
bindings that will permit a single graphics application 
program, written in a particular programming ian- 
guage, to operate any one of a plurality of respectively- 
constructed graphics processors. 

The invention is expressed as a process construct for 
providing a language binding linking a graphics applica- 
tion interface and a graphics processor. The construct 
provides for: translating application language graphics 
specification data into graphics process-specific com- 
mands and attributes; building command and attribute 
data transfer structures for translated graphics process- 
specific commands and attributes; and establishing a 
command and attribute data transfer path for providing 
the built data structures from the graphics application 
interface to the graphics processor. 

The process construct is embodied in a representative 
graphics application programming language context. 
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The above objects and other attendant advantages of 
the invention will become clearer when the following 
detailed description of the invention is read in light of 
the below-described drawings. 


BRIEF DESCRIPTION OF THE DRAWINGS 


FIG. 1 is an illustration of a desk top computer-based 
graphics processing system in which one embodiment 
of the invention is used. 

FIG. 2 is an illustration of a mainframe computer- 
based graphics processing system in which a second 
embodiment of the invention is used. 

FIG. 3 illustrates a chart to be drawn by the systems 
of FIGS. 1 and 2 utilizing the invention. 

FIG. 4 is a flow diagram illustrating, in one major 
branch, an embodiment of the invention for use with the 
system of FIG. 1 and, in the second major branch, an- 
other embodiment of the invention for use with the 
system of FIG. 2. 

FIG. 5 is an illustration of the data structures and data 
and command paths characteristic to the two embodi- 
ments of the invention. 


DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 


Refer now to FIG. 1 for an understanding of a desk 
top personal computer-based graphics processing sys- 
tem. The system consists of a desk top processor such as 
the well-known Personal Computer AT/370 available 
from IBM. One or more graphics output devices such as 
the device 12 can be driven by the processor 10. The 
desk-top graphics processing hardware complement is 
completed by a direct access storage facility (DASF) 
14, such as a disk drive which is attached to the proces- 
sor 10 for extended storage. 

Conventionally, the processor 10 is embodied in a 
desk-top processor module 17 which includes a key- 
board through which user-originated application input 
parameters can be entered into the graphics processing 
system. The console 17 also includes a CRT display 
providing a user/system interaction interface. 

The primary software structures necessary to enable 
the processor 10 to perform graphics processing and 
computation are an operating system (OS) 18 and one or 
more application programs 19a and 198. It is understood 
that the programs 19a and 19d are written in respective 
graphics application programming languages such as, 
for example, FORTRAN and PASCAL. As is conven- 
tional, the operating system 18 includes a control pro- 
gram (CP) 18a which supervises the execution of the 
application programs by managing and scheduling ac- 
cess to the processor resources necessary to support 
program execution. A control program I/O module 
(CPIO) 185 orchestrates the interface between the pro- 
cessor 10 and external devices such as the device 12. 
Each of the application programs 19a and 190 is a series 
of statements constructed by a user that form a program 
for a particular application to be executed using the 
resources of the processor 10. In this case, the applica- 
tion programs 19a and 19d consist of graphics programs 
written by a user to create graphs or charts on output 
devices such as the plotter 12. Completing the graphics 
processing system of FIG. 1 are a graphics processor 
20, which can comprise, for example, the VDI proces- 
sor described above. A graphics device driver (GR 
DRVR) 22 is connected to a specific output device, in 
this case, the device 12. 
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In operation, the operating system 18 can receive 
data and commands directly from one of the application 
programs 19a or 195 and provide resource allocation 
and program connectivity directly to the graphics pro- 
cessor 20. As is known, the commands and data pro- 
vided to the graphics processor 20 are characteristically 
graphical primitives and attributes in the form of meta- 
files. As is known in the art, graphical primitives are 
data structures that correspond to basic graphic figures 
such as lines or shapes. Attributes are data structures 
that define the characteristics of the graphical primi- 
tives. In this regard, attributes include qualities such as 
color, texture, and dimension. 

The VDI processor 20 provides graphical primitives 
and attributes to the graphic device driver. The device 
driver 22 responds to the primitives and attributes by 
converting them into instructions drawn from a set 
specific to the device 12. ; 

In order to make the application programs 19a and 
195 portable from another graphics processing system 
incorporating a graphics processor different than the 
processor 20, graphics language bindings 24a and 24) 
are provided between the application programs 19@ and 
19D, respectively, and the operating system 18. In this 
regard each of the language bindings 24a and 24d con- 
sists of a respective set of subroutines that provide lan- 
guage-specific linkages between graphics application 
programs written in the specific language and the 
graphics processor 20. When used herein, the term “‘lan- 
guage-specific” means that a language binding is in- 
tended to operate with an application program written 
in a specific language. For example, a FORTRAN- 
specific language binding would operate in conjunction 
with application programs written in FORTRAN. 

The language bindings 24a and 24d are maintained in 
the DASF 14 and obtained by the operating system 18 
by conventional storage access means in response to a 
request entered by a user through the keyboard of the 
console 17. Throughout the execution of application 
programs to which the language binding is specific, the 
binding will reside in the main storage of the processor 
10 together with the operating system 18. 

In FIG. 2 there is illustrated another graphics pro- 
cessing system incorporating a mainframe computer 30, 
which can comprise, for example, the IBM product 
available under the name System/370. As is typical, the 
mainframe computer 30 has attached to it application 
input devices 32, which can comprise, for example, 
workstations which utilize the resources of the com- 
puter 30 in a time-shared mode to conduct concurrent 
application program execution. The computer 30 also 
has access to a direct access storage facility (DASF) 34 
and provides graphical output data in the form of de- 
vice instructions to one or more graphic output devices 
such as the device 36. 

The internal processing structure of the mainframe 
computer 30 is conventional and includes a graphics 
processor in the form of a graphics manager 40 (for 
example, the GDDM processor described above), 
which operates to execute graphics application pro- 
grams such as the programs 41a and 41d to produce 
graphs and charts on output devices such as the output 
device 36. The structure of the GDDM is such that it 
operates a plurality of device-specific device drivers 
(DD1-DDN) 41la-41n. The graphics manager 40 char- 
acteristically translates high-level language expressions 
of graphs embodied in application programs into com- 
mand and attribute signals directed to a device driver 
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specified by the application program. The device driver 
translates the commands and attributes into instructions 
for the specific device it controls, with an operating 
system 42 implementing an I/O path between the se- 
lected device driver and the specific device it drives. 
Commands and parameters of specific application 
programs can be provided directly to the graphics man- 
ager 40 to enable it to perform its command and attri- 
bute conversion and device driver selection. However, 


since the structural and operational characteristics of 10 


the graphics manager 40 differ from corresponding 
characteristics of the WDI graphics processor 20, the 
application programs 41a and 410, if provided directly 
to the manager 40, must be written to call the subrou- 
tines specific to the graphics manager 40. The applica- 
tion program interface differences between the graphics 
processors 20 and 40 mean that an application program 
written, for example, to produce a specific chart em- 
bodiment on the output device 36 through the facilities 
of the graphics processing system of FIG. 2 cannot be 
transported unaltered to the graphics processing system 
of FIG. 1 and result in precisely the same chart being 
produced on a similar device such as the output device 
12. 

To provide portability from the graphics processing 
system of FIG. 1 to that of FIG. 2, graphics language 
bindings 44a and 44d are also provided in the graphics 
processing system of FIG. 2. As with the bindings 24¢ 
and 24d, the mainframe system graphics language bind- 
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ings 44a and 44d are functionally positioned between 
the application programs 41a and 414, on the one hand, 
and the graphics manager 40, on the other hand. 

The effect of the language bindings in the systems of 
FIG. 1 and the system of FIG. 2 can be understood with 
reference to a chart, illustrated in FIG. 3, which forms 
the exemplary basis for understanding the invention. 
The graph of FIG. 3 has x and y axes, with axis labels, 
graduation marks, and graduation labels; the graph has 
a title, and three line plots, 46, 47, and 48, each distin- 
guished by having a respective color (although not 
evident on FIG. 3) and a respective point mark where 
the graph changes slope. When language linkings are 
installed in the systems of FIGS. 1 and 2, a single pro- 
gram, written in a particular graphics programming 
language, will be able to cause the production of the 
FIG. 3 graph by either, or both of the systems on similar 
output devices. 

Referring now to Table I, a series of Fortran-type 
statements are representative of a graphics application 
program to draw the chart of FIG. 3. The statements 
used in Table I will be understood by those skilled in the 
art as being typical FORTRAN statements for estab- 
lishing data objects and data attributes and for perform- 
ing functions by calls to specific subroutines. In this 
latter regard, the well-known RC (return code) state- 
ment treats a called subroutine as a function that returns 
the function parameters specified in the parentheses to 


the right of the subroutine designation. 


Z TABLE I 


IMPLICIT INTEGER#4 (A-Z) 
INTEGER#4 DVC,DVCCHS(66), DVCINT(11) 
CHARACTER#8 DVCNAM 
DATA DVC /ZOI1F/ 
DATA DVCNAM /‘DISPLAY'/ 
DATA DVCINT /1,1,1,1,1,1,1,1,0,1,0/ 
INTEGER#4 LINES(3, 10), LINCOL(3) 
DATA LINES /8000,!7000, 12000,8000, 16000,7000, 
20000, 12000, 24000,5000 
8000,5000, 12000,6000, 16000, 10000, 
20000, 17000, 24000, 14000, 
8000,10000, 12000,12000, 16000, 18000, 
20000,7000, 24000,9000/ 
DATA LINCOL /2,3,5/ 
INTEGER#4 AXES(6),XMARKS(4,5), YMARKS(4.4) 
INTEGER#4 XLBLS(2,5), YLBLS(2,4),XTITLE(2), YTITLE(2) 
INTEGER#4 CTITLE(2) 
DATA AXES /4000,21000, 4000,3000. 30000,3000/ 
DATA XMARKS /8000,3000, 8000,3300, 
12000,3000, 12000,3300, 
16000,3000, 16000,3300, 
20000,3000, 20000,3300, 
24000,3000, 24000,3300/ 
DATA YMARKS /4000,7000, 4300,7000, 
4000, 11000, 4300, 11000, 
4000, 15000, 4300, 15000, 
4000, 19000, 4300, 19000/ 
DATA XLBLS /8000,2700, 12000,2700, 16000,2700, 20000,2700, 
24000,2700/ 
DATA YLBLS /3700,7000, 3700,11000, 3700,15000, 3700, 19000/ 
DATA XTITLE /16000,1800/ 
DATA YTITLE /1400,13000/ 
DATA CTITLE /16384,21000/ 
RC = VOPNWK(DVC,DVCNAM,DVCINT,DVCCHS) 
CHRHGT = DVCCHS(61)*4 
RC = VSLCOL(DVC,1) 
RC = VPLINE(DVC,3,AXES) 
DO 10,i = 1.4 
RC = VPLINE(DVC,2,YMARKS(1,1)) 
RC = VSTCOL(DVC,1) 
RC = VSTFNT(DVC,!) 
RC = VSTALN(DVC,2,1,HALGN,VALGN) 
RC = VGTEXT(DVC,YLBLS(1,1),YLBLS(2, 1),"7000") 
RC = VGTEXT(DVC, YLBLS(1,2), YLBLS(2,2),'11000°) 
RC = VGTEXT(DVC,YLBLS(1,3), YLBLS(2,3),"15000") 
RC = VGTEXT(DVC,YLBLS(1,4), YLBLS(2,4).‘19000") 
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TABLE I-continued 
233 DO 20,1 = 1,5 
234 20 RC = VPLINE(DVC,2, YMARKS(I,}D)) 
235 RC = VSTALN(DVC,!,2,HALGN, VALGN) 
236 RC = VGTEXT(DVC,XLBLS(1,1),XLBLS(2,1),‘8000°) 
237 RC = VGTEXT(DVC,XLBLS(1,2),XLBLS(2,2),°12000°) 
238 RC = VGTEXT(DVC,XLBLS(1,3),XLBLS(2,3),‘16000') 
239 RC = VGTEXT(DVC,XLBLS(1,4),XLBLS(2,4),'20000") 
240 RC = VGTEXT(DVC,XLBLS(1,5),XLBLS(2,5),'24000') 
241 RC = VSTCOL(DVC,5) 
242 RC = VSTFNT(DVC,7) 
243 RC = VSTHGT(DVC,2*CHRHGT,CHRWID,CELWID,CELHGT) 
244 RC = VSTALN(DVC,1,2,HALGN, VALGN) 
245 RC = VGTEXT(DVCG,XTITLE(!),XTITLE(2), ‘X-axis title’) 
246 RC = VSTALN(DVC,1,0,HALGN,VALGN) 
247 RC = VSTROT(DVC,900) 
248 RC = VGTEXT(DVC,YTITLE(1), YTITLE(2), ‘Y-axis title’) 
249 RC = VSTROT(DVC,0) 
250 RC = VSTCOL(DVC,6) 
251 RC = VSTFNT(DVC,15) 
252 RC = VSTHGT(DVC,4*CHRHGT,CHRWID,CELWID,CELHGT) 
253 RC = VSTALN(DVC,1,0.HALGN, VALGN) 
254 RC = VGTEXT(DVC,CTITLE(1!),CTITLE(2),‘Chart Title’) 
255 RC = VSMHGT(DVC,2*CHRHGT) 
256 DO 30,1 = 1,3 
257 RC = VSLCOL(DVC,LINCOL(])) 258 RC 


VSMCOL (DVC,LINCOL(])) 


259 RC = VSMTYP(DVC,]) 

260 RC = VPLINE(DVC,4,LINES(1,1)) 
261 30 RC = VPMARK(DVC,4,LINES(1,])) 
262 RC = VRQCHC(DVC,1,CHC) 

263 RC = VCLSWK(DVC) 

264 END 





Table I draws the chart of FIG. 3 by first telling the 
FORTRAN compiler to assume all undeclared vari- 
ables are 4-byte integers (statement 200). Statements 
201-204 define the output device upon which the FIG. 
3 chart is to be produced as a variable (DVC) and spec- 
ify the device as a display. Thus, the chart of FIG. 3 is 
to be produced on a CRT display having an address 01F 
(hexadecimal). The data declaration statement 205 es- 
tablishes default values for the following attributes of 
the graphical primitives to be used in drawing the FIG. 
3 graph: device aspect ratio, line type, line color, line 
mark type, line mark color, text font, text color, and fill 
style, type, and color, in the order of the 10 right-hand 
entries of the statement’s data field. Statement 207 speci- 
fies the x,y coordinate pairs of the lines to be drawn on 
the FIG. 3 chart, while statement 208 establishes the 
respective color of each line. Chart labeling information 
for the x and y axes, for the x and y axis graduation 
marks, for the axis graduation labels, for the axis titles, 
and for the chart title are specified in statements 
209-219. Statement 220 opens the workstation on which 
the application program is to be run; the output device 
is identified as a display device, and the characteristic 
values are returned in the variable DVCCHS. A mini- 
mum height for graphics characters is saved in state- 
ment 221. Statement 222 sets the line color (WSLCOL) 
for the x and y axes, while statement 223 calls a polyline 
subroutine (PLINE) which draws the x and y axes. Y 
axis label marks are drawn by statements 224 and 225. 
The alphanumeric characters comprising the gradua- 
tion labels and axis title for the y axis extend from state- 
ments 226 through 232. In these statements, routines for 
setting specific text attributes of color, form, and align- 
ment are denoted as VSTCOL, VSTFNT, and 
VSTALN, respectively. Once the text attributes have 
been set, the y axis labels are drawn by statements 
229-232. In each of these statements the text drawing 
subroutine has the mnemonic VGTEXT. 
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The subroutines for drawing x axis labels and label 
characters comprise statements 233-240. 

The text attributes for x and y axis titles (color, form, 
and height) result from statements 241-243. The x axis 
title is aligned in statement 244 and drawn in statement 
245. Y axis title alignment is given in statement 246, 
while the text is rotated from the x axis dimension by 90 
degrees by statement 247. The y axis title is written by 
statement 248. The character rotation is restored to the 
horizontal by statement 249. Chart title attributes result 
from statements 250-253. The chart title is written by 
statement 254. The point marker size for the points of 
the graph lines is set via statement 255. Statements 
256-261 draw the three lines of FIG. 3, each with a 
respective color, which is carried over into the respec- 
tive point markers. Thus, the line color and marker 
color (LCOL and MCOL) are set in statements 257 and 
258, respectively, the point marker style is set in state- 
ment 259, and the line and mark pattern is drawn by 
statements 260 and 261. 

Closing out the application program for drawing the 
FIG. 3 chart, statement 262 is a command to the device 
driver to retain the chart on the display until any data 
key on a keyboard is pressed. In this regard, it is implicit 
that the device has processing means for retaining and 
refreshing a complete representation of the FIG. 3 chart 
as specified by the program of Table I. Such devices are 
well known in the art and include some form of a re- 
fresh buffer, frame buffer, or bit map. See the Foley and 
Van Dam reference for a description of a raster-scanned 
display and associated processor at pages 129-133. Fi- 
nally, workstation termination is accomplished by state- 
ments 263 and 264. 

In order to support portability of the Table I graphics 
application program between the graphics processing 
systems of FIGS. 1 and 2, language bindings are pro- 
vided which take into account the characteristic struc- 
ture and operation of each of the graphics processors 20 
and 40. This accounting is illustrated in FIG. 4, which 
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represents an abstraction of a procedure for selecting a 
language binding appropriate to the particular graphics 
processing system as well as the operational steps imple- 
mented by each of the language bindings. Thus, the type 
of graphics processing system is determined in step 50. 
As described above, the two representative graphics 
processing systems can be differentiated on the basis of 
how they define attibutes for graphical primitives mak- 
ing up the representation of a graph. The left-hand exit 
from step 50 leads to a language binding that assumes a 
graphics processing system of the CGI type where 
graphical primitives are partitioned according to a num- 
ber of basic types and attributes are specified with re- 
gard to the graphical primitive type. Thus, for example, 
a color attribute may be set for graph text primitives 
independently of the color for graph lines. On the other 
hand, graphics processors of the GDDM type described 
above define a current set of attibutes for the type of 
graphical primitive currently being drawn and maintain 
those attibutes until they are changed. Thus, if the cur- 
rent color attribute is set at a particular color selection, 
during the drawing of a selected graphical primitive, for 
example, a line, the programmer must remember to 
change the color attibute later in the application pro- 
gram in order to draw, for example, text of a different 
color. As described above, other differences between 
the two representative graphics processors include, but 
are not necessarily limited to, line-drawing coordinate 
procedures, color specification and listing, and text 
character specification and designation. 

In FIG. 4, it is further assumed that the application 
programming language is oriented toward a graphics 
processor employing an attribute partitioning approach, 
as does the VDI graphics processor. Thus, the FOR- 
TRAN statements in Table I reference respective sub- 
routines for setting line color (VSLCOL ), text color 
(VSTCOL), and graph line marker color (WSMCOL). 
It should be evident, however, that the inverse assump- 
tion could easily be made. That is, the application lan- 
guage could be based on the current attribute approach 
of the GDDM graphics processor. 

To further clarify the procedures of FIG. 4, the rela- 
tionships between the language bindings and the respec- 
tive graphics processors and related data objects are 
illustrated in FIG. 5. In FIG. 5, the flow of information 
begins with an application program 52 written in a 
particular language, such as FORTRAN. The applica- 
tion program provides the input data 54 to the respec- 
tive language bindings in the form of function calls and 
parameter specification (func(parm] . . . parmn)), as is 
done in the program of Table I. The inputs are provided 
to one of the language bindings 40a or 24a. 

The graphics language binding 24¢ provides a lan- 
guage-specific linkage between the graphics function 
calls of the application program 52 and the CGI-style 
graphics processor 20. As is stated above, the interface 
is in the form of a conventional metafile 56 which in- 
cludes information in the form of a command (CMD) 
relating to either the drawing of a specific graphics 
primitive or to the setting of a specific graphics primi- 
tive attribute. Specific values for attributes related to 
the drawing of a primitive or setting of a primitive 
attribute are contained in a discrete data (DATA) sec- 
tion of the metafile 56. The function of the graphics 
language binding 24a is to convert the functional and 
parametric data provided by the application program 52 
into the metafile format understood by the graphics 
processor 20. To perform this conversion, the graphics 
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language binding 24a includes a set of graphics function 
subroutines. Each function call of the application pro- 
gram 52 activates a specific one of the graphics subrou- 
tines to effect the conversion to be performed by the 
language binding 24a. The metafiles resulting from the 
conversion are passed to the graphics processor 20; they 
permit the processor 20 to control the device driver in 
drawing a graphics primitive, if required by the com- 
mand portiion of the metafile 56. If the metafile com- 
mand is simply for attribute setting, the graphics proces- 
sor 20 will set an attribute specified by the command to 
the value indicated by the metafile data field. The 
graphics processor 20 maintains lists of attribute group 
settings 58 and 59, with each attribute group corre- 
sponding to a particular set of graphical primitives. As 
is known, a CGI-style graphics processor will, in exe- 
cuting a graphics primitive drawing command, cause 
the device driver 22 to render the primitive with char- 
acteristics determined by the values of the attributes 
associated with the primitive. 

The graphics language binding 44a maps precisely 
the same application program statements as does the 
language binding 24a. However, the language binding 
44a maps the functions and parameters of the applica- 
tion program 52 into a format and according to a se- 
quence understood by the graphics processor 40. In this 
regard, the graphics language binding 444 also includes 
a group of graphics function subroutines; each function 
called by the application program 52 is associated with 
a respective one of the binding subroutines. The func- 
tions and parameters of the application program 52 are 
translated and provided to the graphics processor 40 in 
a format that corresponds to a set of discrete, parallel 
signal interfaces between a pair of electronics equip- 
ments. In this regard, each subroutine of the binding 44a 
will translate the parameters of the calling function 
statement together with predetermined attribute values 
into attribute-setting subroutine calls to the processor 
40. Each subroutine call can be likened to setting the 
value of an individual signal line at the input to the 
graphics processor 40. The attribute subroutine calls 
cause the graphics processor 40 to access a set of pro- 
cessor attribute routines 62 which set the attribute val- 
ues for a device driver 64 identified in the function call 
of the application program 52. Once the graphical prim- 
itive attributes have been set, the subroutine of the lan- 
guage binding 44¢ will call a graphical drawing subrou- 
tine to draw the required graphical primitive. The com- 
mand subroutine call to the graphics processor 40 will 
cause the processor to access a set of primitive com- 
mands 64 from which the proper primitive command is 
selected for operating the device driver 64. Therefore, 
the input sequence for the language binding 44¢ is: first, 
set current attribute values for the graphics processor 
40; and then, activate the proper graphics processor 
primitive command. It should be noted that the selec- 


‘tion of an attribute-partitioning graphics programming 


language to construct the application program 52 re- 
quires the provision of an attribute table, indicated by 
reference numeral 68, which is maintained by the lan- 
guage binding 44a. Since the attribute-partitioning lan- 
guage assumes the maintenance of attribute groups, 
rather than teh constant setting and resetting of current 
attribute values, such a structure must be maintained in 
order to accurately map attribute values set by the pro- 
gram 52 into current attribute settings for the processor 
40. In this regard, the attribute table 68 consists of a 
conventional linked-list of device identifiers, 


5,083,262 


11 

(DDC-DDCn) 68a each of which anchors an attribute 
list for the identified device. The attribute list includes a 
plurality of entries, (ATTR) 685 each corresponding to 
a respective attribute invoked or set by the application 
program 52 for the identified device. The values con- 
tained in the list elements are the value settings for the 
corresponding attributes. 

Referring now to FIGS. 4 and 5, once the graphics 
processor type has been determined in procedure block 
50, the proper language binding is selected. The left- 
hand exit from procedure block 50 corresponds to selec- 
tion of a language binding for the CGlI-style graphics 
processor in which graphical attribute are partitioned 
according to graphical primitive classifications. The 
right-hand exit corresponds to the GDDM-style of 
graphics processor wherein current attribute setting 
values determine the characteristics of graphics primi- 
tives drawn in response to primitive commands. 

With respect to the left-hand exit, representative of 
the procedure followed by the language bindings 24a 
and 245, the metafile object needed for exchanging 
information between the language binding and the 
graphics processor 20 is abstracted as a data structrue in 
step 70. Following this, the procedure accepts the re- 
turn code function calls of the application program 52 
and processes them individually in sequence. Each 
function call includes a return code statement having 
the form illustrated by reference numeral 54 in FIG. 5. 
Initially, in step 72, each function call is inspected to 
determine whether a parameter conversion must be 
made. For example, if the text characters are specified 
in the application program 52 as being EBCDIC char- 
acters, the characters must be converted to ASCII to 
satisfy the requirements of the VDI Graphics Proces- 
sor. If required, the conversion is performed and the 
function routine passes to step 74. In step 74, the called 
function is translated to the corresponding metafile 
command format, following which, in step 76, the pa- 
rameters are converted to attribute values according to 
the data format required by the metafile structure. In 
step 78, the function subroutine builds a specific meta- 
file data structure with the translated command and 
attribute values. In step 80, the routine dispatches the 
built metafile to the graphics processor, together with 
the address of the graphics output device upon which a 
graph according to the application program 52 is being 
produced. When the metafile is transferred to the 
graphics processor 20, the language binding function 
routine provides a return to the application program 52 
with the specified return codes set. 

As shown in the right-hand leg of the FIG. 4 proce- 
dure, the language binding such as 40a responds to the 
application program 52 by first building a device attri- 
bute list for entry into the attribute table 68 of FIG. 5. 
The attribute list is indexed by the identification of the 
output device upon which the graph of the application 
program is to be produced. Initially, the default values 
established for the attributes (in statement 205 of Table 
I, for example) are entered into the attribute list for the 
identified device. Following the building of and initial 
entry into the attribute list, the language binding is 
prepared to accept the sequence of function calls mak- 
ing up the application program 52. As each function call 
is provided to the language binding, the call parameters 
are inspected to determine whether parameter conver- 
sion must be performed. In this regard, the GDDM- 
type graphics processor 40 operates in response to real 
number values, while the CGI-style graphics processor 
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20 operates on integer-valued numbers. Since the appli- 
cation program 52 favors the CGI form of representa- 
tion, each parameter must be converted from its integer 
to its real value in step 84. Next, the attribute value and 
primitive command structure appropriate to the graph- 
ics processor 40 must be established for each function 
called by the application program. In this regard, the 
language binding in step 86 translates the parameters 
received with the function call into attribute values of 
the form recognized by the graphics processor 40. Next, 
the attribute list for the identified graphics output de- 
vice is accessed in step 88. If the current application 
program statement requires setting an attribute, the 
attribute value is set in the appropriate place in the 
attribute list. If the application program statement was 
used only to set an attribute, as opposed to drawing text 
or a symbol or line, the procedure will return to the 
application program with the appropriate return code 
settings after step 88. On the other hand, if the applica- 
tion program statement requires drawing a portion of a 
chart, the procedure will enter step 90. In step 90, the 
language binding calls the necessary attribute-setting 
subroutines of the graphics processor 40. Each of the 
attribute-setting subroutines is provided with the value 
to which the attribute affected by the called subroutine 
is to be set. Following attribute setting, the language 
binding, in step 92, will call the primitive command 
subroutine of the graphics processor 40 that is necessary 
to draw the required primitive or primitives. If re- 
quired, the language binding subroutine will translate 
the function into a series of primitive commands in 
order to accomplish the required function. For exam- 
ple, if the function call in the application program is 
appropriate for drawing a set of lines, such as axes, the 
invoked language binding function routine will call the 
graphics processor primitive command for line draw- 
ing. To draw one or more lines, the language binding 
must call the primitive command to establish the cur- 
rent point and then call the line-drawing primitive com- 
mand to draw the line segments. Once the required 
drawing task is completed, the language binding fol- 
lows appropriate return procedures and obtains the next 
function call of the application program. 

Referring once again to Table I, each of the language 
bindings consists of a set of callable functions or subrou- 
tines. Each graphics RC statement in Table J invokes a 
specific function in a language binding which translates 
the statement, and the attribute parameters in the state- 
ment’s parameter field into a command and attribute 
data tailored to the characteristics of a grahics proces- 
sor. Each binding thus maps the following representa- 
tive generic functions called in the application program 
to a specific subroutine; VSLCOL (set line color); 
VPLINE (draw a polyline); VSTCOL (set text color); 
VSTFNT (set text font); VSTALN (set text alignment); 
VGTEXT (write text); WSTHGT (set text height), 
VSTROT (set text baseline rotation); VWSMHGT (set 
line marker size} WSMCOL (set mark color); 
VSMTYP (set mark type) and VPMARK (draw poly- 
mark). It is to be understood that these are only repre- 
sentative of a great number of generic graphics func- 
tions that can be called by an application program and 
supported by corresponding language binding function 
routines. 

Refer now to Tables II-V which provide specific 
representations of function routines included in the 
language binding 24a. The representative function rou- 
tines are explained in light of specific graphics function 


5,083,262 


13 

calls in the graphics application program of Table I. It 
is to be noted that the entries in Tables II-V are in a 
pseudo-code which is not compilable, but which is 
nonetheless representative of coding functions used to 
build the language binding, and which is easily trans- 
lated by those skilled in the art into compilable state- 
ments. 

It is assumed for the sake of the following illustration 
that the language binding statements of Tables II-V are 
directed to the support of graphics functions performed 
in a desk-top graphics processing system such as would 
be based upon the AT/370 desk-top computer available 
from IBM. In this regard, the graphics functions in such 
a desk top computing system are performed by convert- 
ing the graphics primitive associated with a function 
called by the graphics application program of Table I 
into its corresponding graphics processor metafile com- 
mand. For the purposes of the VDI graphics processor 
example (which embodies the CGI Standard), the meta- 
file data structure is represented by the statements 
300-303 of Table II. 


TABLE II 
300 Variables 
301 metafile = structure 
302 command:integer 
303 values:array[]..n} of integer 


Statements 300-303 are well-understood declaration 
statements which establish the definition of a metafile 
data structure that contains: a command in integer form, 
constituting the graphics primitive command corre- 
sponding to a graphics primitive function to be per- 
formed and an array of integer values corresponding to 
the graphics primitive data establishing the attribute 
values in the metafile. 

The specific language binding function routines of 
Tables II-V correspond to the procedures invoked by 
the graphics language binding 24a in response to spe- 
cific function calls in the graphics application program 
of Table 1. The function calls selected for the following 
examples are those in statements 222, 223, and 229. In 
explaining the language binding embodiment for each 
statement, it is presumed that the graphics processor 20 
has available in storage indexed attribute lists providing 
an attribute value or characteristc for a particular index 
value. Thus, there will be respective attribute list entries 
for line type, line color, graph marker type, graph 
marker color, graph text font type, graph text color, fill 
style, fill type, an fill color. It should be evident that 
since there are no filled characters in the FIG. 3 graph, 
the last three attribute lists will not be accessed. How- 
ever, the open workstation statement (220) requires an 
index value to be established for each attribute. As 
stated above, the initial values of these attributes and 
also an aspect ratio attribute are set by statement 205 to 
initial values. These initial values can be changed 
through the program, and, in fact the line type, line 
color, marker type, marker color, text font, and text 
color values are all changed from their initial setting. It 
is understood that the VOPNWK call (statement 220) 
activates an appropriate language binding function rou- 
tine to enter the default values into the appropriate 
attribute group setting lists maintained by the graphics 
processor 20. 


TABLE I] 


304 Function Vslcol (parm ]:integer,parm2:integer):integer 
305 Constants 
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14 
TABLE III-continued 


306 set_line_color = 16#5082 

307 = Variables 

308 device_address:defined parm! 

309 color_index:defined parm2 

310 ~—- Begin 

311 metafile.command = set_linecolor 

312 metafile.values[1] = color_index 

313 Vslcol = CP_graphics_write(device_address,metafile) 
314 Return 

315 End 





Turning now to statement 222 of the graphics appli- 
cation program, Table III provides the set of function 
routine steps necessary to execute the setting of the line 
color attribute to an index value of 1 for the output 
device identified by the DVC data field. The function 
called is VSLCOL and its input parameters PARMI 
and PARM2 are the device address (DVC) and the 
desired color index setting, respectively. For reference, 
the VSLCOL functional subroutine is defined in state- 
ment 304. In statements 305 and 306, the metafile com- 
mand for setting line color is declared as a hexadecimal 
value. The address of the device driver controlling the 
specified output device and the color index value are 
defined as the function parameters by statements 
307-309. The function routine begins in step 310 by 
inserting the set line color command and color index 
value into the metafile command and data fields, respec- 
tively. Next, a language binding subroutine for passing 
the metafile to the graphics processor 20 addressed for 
output to the graphics device is summoned in step 313. 
Return is made to the application program in step 314 
and the set line color function routine is ended in step 
315. 

Turning now to the program statement 223, Table IV 
constitutes a language binding procedure to link the 
program to the graphics processor 20. As stated above, 
statement 223 is used by the programmer to draw the x 
and y axes in the FIG. 3 chart. 


TABLE IV 


330 Function Vpline(parm1:integer,parm2:integer, 
parm3:array[1..n,1..2] of integer):integer 

331 Constants 

332 output_polyline = 16#403F 

333 Variables 

334 device—address:defined parm] 

335 point_count:defined parm2 

336 coordinates:defined parm3 

337 Begin 

338 metafile.command = output—polyline 

339 metafile.values[1] = 4*point_count 

340 For i = 1 to point_count 

341 For j = 1 to2 

342 metafile. values[(2*(i— 1))+j+1] = coordinates[i,j] 

343 End 

344 End 

345 Vpline = CP_graphics_write(device_address,metafile) 

346 Retum 

347, End 





Table IV provides a function routine for drawing a 
polyline (VPLINE) on the addressed device, with the 
polyline consisting of two segments as defined by three 
XY coordiinate pairs. The axes parameteer in the 
VPLINE statement gives the point coordinate data 
defined in statement 212 of Table I. The function of 
Table IV is named and defined by statement 330. The 
constant value defining the polyline drawing command 
is set in statements 331 and 332. Statements 333-336 
define the variables used in the graphics processor sub- 
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routine and associate those values with the parameters 
delivered with the VWPLINE statement. The defined 
metafile structure is filled with a line-drawing command 
and coordinate values between which the axes are to be 
drawn by statements 337-343. Statement 345 calls the 
graphics processor subroutine for passing to the graph- 
ics processor 20 the structured metafile containing the 
command and data for drawing the axes on the ad- 
dressed device. It should be noted that the line color 
attribute defining the color in which the axes are to be 
drawn has been set by the language binding procedure 
of Table III, corresponding to the function call of state- 
ment 222 in Table I. 

Table V is representative of a language binding func- 
tion routine for executing a text drawing function. In 
this case, the text drawing function is the one in the 
Table I statement numbered 229. The purpose of state- 
ment 229 is to place the graduation value “7,000” at the 
appropriate position adjacent the y axis of FIG. 3. 


TABLE V 


380 = Function Vgtext(parm]}:integer,parm2:array[1..2] of 
integer,parm3:string):integer 

381 Constants 

382 output_graphic_text = 16#411F 

383 Wariables 

384 device_address:defined parm] 

385 coordinates:defined parm2 

386 ebcdic__string:defined parm3 

387 ascii_string:string 

388 Begin 

389 ascii_string = ebcdic_to_ascii (ebcdic_string) 

390 If ((Length(ascii_string) mod 2) > 0 then 

ascii_string = ascii_string + Chr (0) 

391 metafile.ccommand = output_graphic_text 

392 metafile. values[1] = Length(ascii_string) + 8 

393 metafile.values[2] = coordinates[1] 

394 metafile.values[3] = coordinates[2] 

395 metafile.values[4] = 0 

396 metafile. values[5] = Length(ebcdic_string) 

397 For i = 1 to Length(ascii__string) by 2 

metafile[i+5] = Val(Substr(ascii_string,i,2)) 

398 End 

399 Vgtext = CP_graphics_write(device_address,metafile) 

400 Return 

401 End 





In Table V, statement 380 links the language binding 
routine to the VGTEXT function call and accepts as 
input parameters the device address (PARM1), the x,y 
coordinates locating the text (PARM2), and the string 
of EBCDIC characters defining the text (PARM3). It 
should be noted that the text block to be drawn is also 
affected by the VSTALW statement (statement 228) 
which sets the alignment relationship of text characters 
on the graph. Recall, too, that a text rotation attribute 
has been set to a default setting in statement 205 of 
Table I; this establishes the rotational correspondence 
of text characters with respect to a horizontal baseline 
on the graph. Steps 381 and 382 establish the text writ- 
ing command that is understood by the graphics proces- 
sor 20. Steps 383-386 associate metafile parameters with 
the parameters PARM1-PARMs3. An ASCII variable is 
defined as a string in statement 387. Conversion of the 
EBCDIC character string to an ASCII character string 
is accomplished in steps 390 and 391. The established 
metafile data structure is filled with command and data 
values in steps 392-398 with the graphic text production 
command being placed in the metafile in step 391. The 
length of the metafiile data is set as the first metafile 
value. The x and y coordinates are the second and third 
metafile data values, respectively. The length of the 
string is given in statement 396 and statements 397-399 
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place the ASCII representation of the string into the 
metafile. Statement 399 calls a routine that passes the 
structured metafile to the graphics processor. 

With regard now to the right-hand branch of the 
procedure of FIG. 4, Tables VI-IX provide representa- 
tive function routines for the language binding 40a of 
FIG. 5 that are appropriate to link statements of the 
graphics application program 52 to the graphics man- 
ager 40, exemplified by the GDDM graphics processor 
described above. 


TABLE VI 
500 Variables 
501 attributes = structure 
502 next__attribute_pointer:—attributes 
503 device_address:integer 
504 gddm_device_id:integer 
505 line_style:integer 
506 line_color:integer 
507 line_width:integer 
508 text_color:integer 
509 text_height:integer 
510 text_aspect_ratio:real 
511 text_horiz_alignment:integer 
$12 text_vert_alignment:integer 
513 sin_text_rotation—_angle:rea] 
514 cos__text_rotation_angle:real 
515 symbol]_set—id:integer 
516 color_map:array[1..16] of integer 
517 base__attribute__pointer:—attributes 
518 current__attribute__pointer:—attributes 
519 Constants 
$20 line_type—map:array[1..6] of integer 
521 text_cell_scale_factor:real 





In Table VI, the variables making up an attribute 
structure are declared in statements 501 and 503-516. 
The attribute structure is rendered in linked-list form by 
the current, next, and base attribute pointers. The base 
attribute pointer is the list anchor, the current attribute 
pointer is the address of the list element currently being 
inspected, and the next attribute pointer is the address of 
the next element in the list following the one currently 
being inspected. Constants are defined in statements 
519-521. 

Graphics functions in a mainframe graphics process- 
ing system, such as the system of FIG. 2 employing a 
GDDM-type graphics processor, are performed by 
calling one or mroe GDDM graphics primitive func- 
tions. These functions are documented in the IBM 
GDDM Base Programming Reference for Release for 
(Publication No. SC32-0101). Since GDDM-type 
graphics processors do not partition graphics attributes 
by primitive group classification, but have only the 
concept of current attributes, the primitive group attri- 
butes set in the Table I program must be saved in the 
linked list described above and established in Table VI. 
Because the GDDM.-type processors support multiple 
output devices, the variables applicable to a graph pro- 
duced on a particular output device are kept in a list 
identified by the address of the device with which it is 
associated. 

Refer now to Table VII, which describes a procedure 
for implementing the VSLCOL function call of applica- 
tion program as exemplified by statement 222. 


TABLE VII 
$30 Function Vslcol(parm]:integer,parm2:integer):integer 
531 Variables 
$32 device_address:defined parm] 
533 color_index:defined parm2 
534 Begin 
535 current_attribute_pointer = Locate_attribute list 
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TABLE VII-continued 


(device_address) 


536 current_attribute_pointer—line__color = color_index 
537 Vslcol = 0 

538 Return 

539 End 





In Table VII, the VSLCOL function is named and 
characterized in statement 530. The inputs of the func- 
tion call are defined as the device address (PARM}) and 
the color attribute for the VDI-type graphics processor 
based on graphical primitive partitioning. The proce- 
dure consists essentially of a first step of locating the 
attribute list for the requested device, and a second step 
of saving the new line color index at the corresponding 
list element in the located attribute list. In this regard, 
step 1 is accomplished by statement 535 and step 2 by 
statement 536. The return code is set in statement 537 
and the return to the application program is effected in 
statements 538 and 539. 

The function routine for the line drawing call exem- 
plified by (statement 223) is given in Table VIII. 


TABLE VIII 


550 Function Vpline(parm]:integer,parm2:integer, 
parm3:array[]..n,1..2] of integer):integer 

551 Variables 

$52 device_address:defined parm1 

553 point_count:defined parm2 

554 coordinates:defined parm3 

555 x-coordinates:array[1..n] of real 

556 y-coordinates:array[1..n] of real 

557 Begin 

558 For i = 1 to point_count 

559 x-coordinates{i] = Integer_to_real (coordinates[i,!]) 

560 y-coordinates[i] = Integer_to—real (coordinates[i,2]) 

561 End 

562 current_attribute_pointer = Locate_attribute list 

(device—address) 
563 GSLW(current-attribute_pointer—line_ width) 
564 GSCOL(color_map(current—attribute_pointer— 
line—color)) 
565 GSLT(line_type_map(current_attribute__pointer— 
line_type)) 

566 GSMOVE(x-coordinates[ 1], y-coordinates[1]) 

567 If point_count = 1 then 

568 GSPLNE(point—count,x-coordinates[1],y-coordinates[1]) 

569 Else 

570 GSPLNE(point_count,x-coordinates[2], y-coordinates[2]) 

571 Vpline = 0 

572 Return 

573. End 





For the GDDM graphics processor 40 the line draw- 
ing command requires setting line width, line color, line 
type, and line coordinate attributes. These parameters 
are either obtained from the attribute list 64 which con- 
tains a default value or are set in the parameter field of 
a function call statement. In this regard, the function 
call parameters are the device address (PARM1), the 
line point count (PARM2), and the x, y coordinates of 
the axes. These parametric associations are all made in 
statements 551-556. Statements 558-560 convert the 
integer values of the x, y coordinates in the function call 
parameter field to real coordinates and reorder them as 
required by the processor 40. Statement 562 locates the 
attribute list and statements 563-566 set the current 
attributes of line width, line color, and line type for the 
graphics processor 40. In the well-known GDDM sys- 
tem, these attribute function calls are denoted as 
GSLW, GSCOL, and GSLT, respectively. It is noted 
that statements 564 and 565 also translate the color 
index and line style from their VDI to their GDDM 
representations. Statement 566 sets up the access line- 
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drawing procedure by referencing the procedure to the 
first set of x, y coordinates. Then, statements 567-570 
draw the axes using the converted coordinates. State- 
ment 571 sets the return code for the called function and 
statements 572 and 573 return program execution to the 
Table I program. 

A representative text-drawing function routine by 
statement 229 of Table I is supported by the linkage 
procedure of Table IX. 


TABLE IX 

509 Function Vgtext (parml:integer, parm2:array[}..2] of 

integer, parm3:string):integer 

591 Constants 

592 gddm-vector_mode = 3 

593 Variables 

594 device_address:defined parm] 

595 coordinates:array{1..2] of defined parm2 

596 ebcdic_string:defined parm3 

597 text_location:array[1}..2] of real 

598 text_box._x:array[1..4] of real 

599 text_box_y:array[1..4]} of real 

600 text_cell_height,text_cell_width:real 

601 Begin 

602 Fori = 1 to2 

603 text_location[i}= Integer_to_real (coordinates[i]) 

604 End 

605 current__attribute_pointer = Locate-attribute 
list (device_address) 

606 GSCM(gddm_vector_mode) 

607 GSCS(current_attributepointer—+symbol_set_id) 

608 text_cell_height = text_cell_scale_factor*Integer_ 
to_real(current_attribute_pointer—text_height) 

609 text_cell_width = text_aspect—ratio*text_cell_height 

610 GSCB(text_cell_width,text_cell_height) 

611 GSCA(current_attribute_pointer—cos_text_rotation— 
angle, current_attribute—pointer—sin_text_ 
rotation_angle) 

612 GSQTB(Length(ebcdic_string),ebcdic_string,4,text_ 

box__x, text_box_y) 

613 text_location{1} = text_location[1]—(Integer_to_real 
(current__attribute_pointer—text_horiz__alignment) 
*((text_box_x[4] — text_box_x[2])/2)) - Integer_ 
to_real(current_attribute__pointer—text_vert_ 
allignment)*((text_box_-x[1]—text_box_x[2]/2)) 

614 text_location[2] = text_location{2] - (Integer_to_real 
(current_attribute__pointer—text_horiz_allignment)* 
((text_box_y[4] — text_box_y[21]/2))-(Integer_ 
to_real (color_map current_attribute_pointer—text_ 
vert_allignment)*) 
((text_box_y[1]—text_box_y[2]/2)) 

615 GSCOL(current_attribute_pointer—text_color) 

616 GSCHAR(text—location[1],text_location[2],Length 
(ebcdic_string,ebcdic_string) 

617 Vegtext = 0 

618 Return 

619 End 





The parameters provided to the procedure of Table 
IX include the device address (PARM1), the coordi- 
nates defining the location of the text (PARM2), and the 
EBCDIC character string defining the text (PARM3). 
With regard to the coordinates locating the text, it 
should be noted that as with the example of Table V for 
the graphics processor 20, text location is also deter- 
mined by the values for text alignment (VSTALN) and 
rotation (VSTROT). Reference to Table I will inform 
that statement 228 will have resulted in a change in 
setting of text alignment for the case of the y axis gradu- 
ation labels, while the text rotation parameter will have 
its default value. 

The other variables defined for the text drawing func- 
tion include: the text location as an array of real num- 
bers, the computed extent of the text on the screen as a 
two-dimensional array of real numbers, and the text cell 
height and width as real numbers. 
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Finally, it should be noted that the GDDM instantia- 
tion of the graphics processor 40 includes a multi-mode 
generator for text drawing. When drawing text, a 
GDP graphics processor can draw text characters as 
images or as vectors. In this case, in order to provide the 
programmer with the ability to directly scale the size of 
the text by the well-known boxing or extent technique 
(see Foley and Van Dam, pp. 375-376), the vector 
mode of character generation is invoked by setting the 
vector mode in statement 592. 

To support the vector mode of character generation, 
the point coordinate values in the parameter field of the 
calling function are converted to real values by state- 
ments 602-604. Next, the attribute list for the requested 
device is obtained by means of statement 605. In state- 
ment 606, the vector character drawing mode of the 
graphics processor is set so that the character size, 
alignment, and rotation values set in the application 
program of Table I can be used. Next, the current attri- 
bute list is accessed in steps 607 and 608 to select a 
character font (symbol set) and text height. In step 609, 
the text cell width is derived by multiplying the text cell 
height set in statement 608 by a predetermined text 
aspect ratio. The text cell width and height attributes 
are set for the processor in statement 610. In statement 
611, the current attribute list is accessed to obtain base 
line rotation values necessary to correctly align the y 
axis label being drawn. Statements 612-614 perform 
horizontal and vertical alignment of the label being 
currently drawn, and statement 615 accesses the current 
attribute list to set the color of the text being drawn. In 
statement 616, the graphics processor command which 
causes the driver to draw the current label at the loca- 
tion and with the attributes previously defined is called. 
Statement 617 sets the return code and statements 618 
and 619 return program control to the application pro- 
gram of Table I. 

Although the language binding examples described 
hereinabove are based upon use of VS FORTRAN as 
the graphics application programming language, it will 
be evident to those skilled in the art that language bind- 
ings can also be constructed for interfacing graphics 
application programs written in other languages such as 
Pascal, and Assembler H. Furthermore, it will be evi- 
dent that language bindings can be provided for inter- 
preted user languages such as the REXX (restructured 
extended executor) language available in the IBM soft- 
ware product denoted as VMSP-3 (virtual machine/- 
system product-3). The REXX language can be used for 
developing applications quickly by using instructions 
which translate easily to functions or routines expressed 
in other high-level languages such as FORTRAN. 

Finally, although language binding function routines 
are described only for setting line color, drawing lines, 
and drawing text, it will be understood by those skilled 
in the art that other functional routines can be con- 
structed for setting any graphical attribute or executing 
any graphics drawing function within the capabilities of 
the graphics processor linked by a language binding to 
an application program. 

Obviously, many other modifications and variations 
of this invention are possible in light of these teachings. 
Therefore, it is to be understood that within the scope 
of the appended claims, the invention may be practiced 
in forms other than those specifically described. 

I claim: 

1. A linkage system for providing a set of bindings 
which enable a graphics application program written in 
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a predetermined program language to be executed in 
one or the other of two different graphical processor 
environments independent of the programming lan- 
guage, comprising 

a graphics output device; 

a graphics application process means for providing a 
series of user language-specific process statements 
defining a graph; 

a graphics process means responsive to graphics com- 
mands and graphics attributes for producing device 
signals corresponding to said graph; 

a graphics output device driver connected to said 
graphics process means and to said graphics output 
device and responsive to said device signals for 
producing said graph on said graphics output de- 
vice; 

a graphics language binding means in communication 
with said graphics application process means in one 
or the other of said two different graphical proces- 
sor environments for translating said process state- 
ments into said graphics commands and graphics 
attributes; 

a transfer structure means in said graphics language 
binding means for building a data transfer struc- 
ture; and 

a transfer process means in said graphics language 
binding means for transferring said graphics com- 
mands and graphics attributes from said language 
binding means to said graphics process means in 
one or the other of said two different graphical 
processor environments, said graphics attributes 
being transferred in said data transfer structure. 

2. The linkage system of claim 1 wherein said graph- 
ics process means in one of said two different graphical 
processor environments recognizes two or more graphi- 
cal primitive groups and maintains separate respective 
sets of graphics attributes, each set of graphics attributes 
including attributes of a respective graphical primitive 
group. 

3. The linkage system of claim 2 wherein said data 
transfer structure in one of said two different graphical 
processor environments is a metafile. 

4. The linkage system of claim 2 wherein said transfer 
process means in one of said two different graphical 
processor environments includes a message-passing 
procedure. 

5. The linkage system of claim 1 wherein said graph- 
ics process means in one of said two different graphical 
processor environments maintains a current value for 
one or more graphics attributes and responds through 
appropriate protocals to a translated graphics command 
by producing device signals corresponding to a prede- 
termined graphical primitive having graphics attributes 
determined by said value. 

6. The linkage system of claim 5 wherein said graph- 
ics process means in one of said two different graphical 
processor environments includes attribute process 
means for setting said value and primitive command 
means for setting device signals corresponding to 
graphics primitives and said data transfer structure in 
one of said two different graphical processor environ- 
ments includes one or more program calls for activating 
said attribute process means and for activating said 
primitive command means. 

7. The linkage system of claim 6 wherein said transfer 
Process means in one of said two different graphical 
processor environments includes a function subroutine 
having said program calls. 


5,083,262 


21 
8. A computer programming device for providing 
portability of a graphics application program written in 
one programming language between two different 
graphical processors each having a different graphics 
interface connected to a peripheral device driver for a 
peripheral graphics unit such as a printer, plotter, dis- 
play, including 
first transfer means in communication with a first 
graphics interface for providing a command and 
data path to a first graphical processor wherein 
graphical primitives are partitioned according to 
basic types and attributes are specified with regard 
to such basic types; 
second transfer means in communication with a sec- 
ond graphics interface for providing a transforma- 
tion of signals to a second graphical processor 
wherein a current set of attributes are defined for 
the type of graphical primitive currently being 
drawn and such attributes are maintained until 
changed; and 
language binding means for receiving function calls 
and parameter specifications generated by the 
graphics application program and converting them 
either into a suitable format for transfer in a data 
transfer structure via said first transfer means to 
said first graphics interface or alternatively into a 
different format and sequence using attribute set- 
ting subroutines and primitive command subrou- 


Di 


20 


30 


35 


45 


50 


55 


65 


22 


tines for transfer via said second transfer means to 
said second graphics interface, and wherein said 
first and second graphical processors are indepen- 
dent of any programming language. 

9. The computer programming device of claim 8 
wherein said one programming language is taken from a 
group consisting of Fortran, Pascal, Assembler H, Basic 
C, and REXX. 

10. The computer programming device of claim 8 
wherein said first graphics interface conforms to an 
industry standard identified as CGI (Computer Graph- 
ics Interface). 

11. The computer programming device of claim 8 
wherein said second graphics interface conforms to the 
Graphics Data Display Manager (GDDM) standard. 

12. The computer programming device of claim 8 
wherein said second graphical processor is incorpo- 
rated as part of a mainframe-type computer system. 

13. The computer programming device of claim 8 
wherein said first graphical processor is incorporated as 
part of a PC-type desktop computer system. 

14. The computer programming device of claim 8 
wherein other differences between said first graphical 
processor and said second graphical processor include 
line drawing coordinate procedures, color specification 
and listing, and text character specification and designa- 


tion. 
* * * * * 


